now  I^Oief6 
Paper  Number 

Experiences  Linking  Vehicle  Motion  Simulators  to 

Distributed  Simulation  Experiments 

Richard  W.  Jacobson 

us  Army  TARDEC,  National  Automotive  Center 


ABSTRACT 

The  Tank  Automotive  Research,  Development  and 
Engineering  Center  (TARDEC)  has  been  at  the  forefront 
in  developing  the  pardware  and  software  for  physics- 
based,  ride  motion  simulation,  for  over  30  years.  In  order 
to  share  this  capability  with  the  simulation  community,  it  is 
necessary  to  deveipp  an  interface  to  link  these  motion 
simulators  with  other  DoD  distributed  simulations. 
Various  technologiels  such  as  the  Distributed  Interactive 
Simulation  (DIS),  Network  Data  Delivery  Service 
(NDDS™)  and  the  High  Level  Architecture  (HLA)  have 
been  used  to  try  and  accomplish  this  goal.  The 
distributed  simulctions  of  interest  are  the  Semi 
Automated  Forces  (SAF)  ones  such  as.  Modular  SAF 
(ModSAF),  OneSAf  Test  Bed  (0TB)  Version  1.0  and 
0TB  Version  2.0.  There  have  been  five  projects,  which 
incorporated  varioiJis  levels  of  interoperability.  These 
projects  have  provided  extensive  experience  and  many 
lessons  learned  to  support  the  continuing  effort  to 
develop  a  more  robgst  and  flexible  distributed  simulation 
environment  within  the  GVSL  at  TARDEC. 

This  paper  will  describe  the  current  simulators  and 
simulation  environrtient  at  TARDEC,  each  of  the  five 
projects  associated  with  developing  a  distributed 
simulation  capability  and  the  current  ongoing  effort  to 
create  a  useful  simulation  federation  consisting  of  the 
motion  simulators  pnd  0TB  Version  2.0.  In  order  to 
develop  this  federation  the  Federation  Development 
and  Execution  Process  (FEDEP)  is  being  used.  The 
FEDEP  is  a  generalized  process  for  developing 
federations  that  h$s  evolved  from  the  activities  and 
experiences  of  the  simulation  community. 

INTRODUCTIOhJ 

INTRODUCTION  TO  THE  TARDEC  PHYSICAL 
SIMULATION  ENVIRONMENT  -  The  TARDEC  Ground 
Vehicle  Simulation  Laboratory  (GVSL)  has  developed  a 
unique  capability  with  its  RMS  and  CS/TMBS  man-rated 
physics  based  vehicle  motion  simulators.  These  6 
degree-of-freedom  (DOF)  simulators  provide  the 
capability  to  recreate  realistic  vehicle  ride  motion 
characteristics  within  the  laboratory.  They  can  realistically 


simulate  the  motion,  visuals  and  sound  of  a  vehicle 
system.  The  simulators  are  currently  configured  for  the 
following  vehicles:  HMMWV,  Ml,  M2  and  Stryker.  These 
simulators  are  used  to  perform  research  into  vehicle 
motion  effects.  They  provide  a  controlled  environment 
that  is  not  affected  by  the  kinds  of  variability  that  is  found 
when  performing  testing  in  the  field. 

DESCRIPTION  OF  THE  RMS  AND  CSH'MBS  -  The  RMS 
and  CS/TMBS  are  six  DOF,  man-rated,  motion  simulators 
used  to  perform  research  in  the  areas  of  military  vehicle 
systems. 


Figure  1.  Ride  Motion  Simulator  (RMS) 

The  RMS  (Figure  1)  is  a  reconfigurable  simulator  that  is 
used  to  evaluate  single  person  vehicle  stations  such  as  a 
driver  or  commander.  The  total  system  has  a  bandwidth 
of  up  to  40  Hz.  The  system  is  used  for  the  following: 
Soldier-in-the-loop  simulation,  war-gaming  exercises. 
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crew  station  an(j  component/development,  and 
workload/task  perfotfmance  investigations. 

The  CS/TMBS  (Figure  2)  is  also  a  reconfigurable 
simulator  that  is  us  ad  to  evaluate  large,  turret  or  crew 
stations.  The  system  is  capable  of  running  with  a  fully 
active  crew  station.  The  CS/TMBS  can  support  up  to  25 
tons.  The  total  system  has  a  bandwidth  of  up  to  8  Hz. 
The  system  is  used  for  the  following:  gun/turret  drive 
characterization,  control  system  algorithm  development, 
turret  system  structure  development,  baseline  vs. 
modified  studies  crew  station  and  soldier/machine 
interface  development. 


Figure  2.  Crew  Station/Turret  Base  Motion  Simulator 
(CS/TMBS) 


DISTRIBUTED  SIMULATION  -  In  order  to  make  the  RMS 
and  CS/TMBS  more  available,  it  is  necessary  to  have 
them  participate  in  simulated  military  operations 
experiments,  both  locally  and  with  other 
simulations/simulators  around  the  country.  In  a 
“Distributed  Simulaiion”,  different  organizations  can  run 
different  simulations/simulators  and  design  experiments 
to  evaluate  things  that  affect  military  operations,  like 
survivability,  tactics,  logistics,  detectability,  etc.  These 
experiments  may  be  configured  between  simulations 
running  at  the  sane  installation,  or  they  may  involve 
systems  in  every  corner  of  the  country. 

The  Defense  Modeling  and  Simulation  Office  (DMSO) 
initiated  the  standatxfization  of  simulation  interoperability. 
This  effort  has  produced  the  Institute  of  Electrical  and 
Electronics  Engineers  IEEE  Standard  1278  Distributed 
Interactive  Simulation  (DIS)  and  (IEEE)  Standard  1516  for 
Modeling  and  Simulation  (M&S)  High  Level  Architecture 
(HLA).  These  two  standards  provide  the  framework  that 
will  allow  legacy  singulations  to  interoperate  with  current 
and  future  simulations.  The  DIS  Standard  1278  was 
developed  first  and  was  a  definition  of  the  low  level 
network  protocols  needed  to  communicate  between 
simulations  on  a  network.  The  experiences  with  DIS  led 


to  the  development  of  the  HLA  Standard  1516  which 
describes  a  high  level  framework  for  the 
intercommunication  of  simulations.  The  focus  of  this 
paper  will  be  on  HLA. 

A  short  description  of  HLA  is  necessary  to  provide  a 
background  in  simulation  interoperability.  An  HLA 
distributed  simulation  is  called  a  Federation.  The 
Federation  consists  of  two  or  more  Federates.  A 
Federate  is  a  single  simulation.  The  list  or  description  of 
all  objects,  attributes  and  interactions  that  is  to  be  shared 
between  all  of  the  Federates  in  a  Federation  is  called  the 
Federation  Object  Model  (FOM).  Each  simulation  also 
has  a  list  of  the  objects,  attributes  and  interactions  that  it 
will  share  with  the  Federation.  This  is  called  the 
Simulation  Object  Model  (SOM).  The  SOM  is  a  subset  of 
the  FOM.  All  communication  of  data  within  a  federation  is 
done  through  the  Run  Time  Infrastructure  (RTI),  which  is 
a  separate  program  from  the  Federates.  The  federation 
that  is  being  developed  within  the  GVSL  consists  of  the 
RMS  and  an  Army  military  combat  simulation  program 
called  OneSAF  Test  Bed.  OneSAF  stands  for  One  Semi 
Automated  Forces. 

In  order  to  leverage  all  of  the  simulation  work  that  has 
been  done  in  the  past,  the  Army  is  currently  supporting 
an  effort  to  combine  its  various  Semi  Automated  Forces 
(SAF)  simulations  into  a  single  simulation  (OneSAF). 
Semi  Automated  Forces  describes  the  simulations 
capability  to  create  virtual  forces,  which  exhibit  the 
behaviors  of  real  forces.  This  effort  is  progressing  in 
phases  in  order  to  maintain  existing  simulation 
capabilities.  This  effort  builds  on  the  work  done  to 
develop  Modular  SAF  (ModSAF).  The  current  phase  has 
produced  the  OneSAF  Test  Bed  (0TB).  0TB  Version 
2.0  has  just  been  released.  0TB  is  the  recommended 
SAF  to  be  used  until  the  OneSAF  Objective  System 
(OOS)  is  completed  in  2006. 

VISION  -  In  order  to  make  RMS  and  CS/TMBS  a  better 
research  tool,  the  TARDEC  GVSL  is  developing  the 
necessary  simulation  infrastructure  to  allow  these 
simulators  to  link  with  other  DoD  simulations  using  HLA. 
As  part  of  this  effort  an  HLA  federation  is  being 
developed  which  will  consist  of  two  federates  the  RMS 
and  OTB  Version  2.0.  This  federation  will  use  the  DMSO 
1 .3NGv6  HLA  specification  and  Run  Time  Infrastructure 
(RTI).  The  development  of  the  interoperability  of  HLA 
with  the  RMS  and  CS/TMBS  will  provide  a  more  flexible 
and  productive  simulation  environment.  The  past  work 
on  developing  a  distributed  simulation  environments  for 
the  RMS  will  be  described  in  the  next  section. 

LINKING  TARDEC  SIMULATORS  INTO 
DISTRIBUTED  SIMULATIONS 

DESCRIPTIONS  OF  PAST  WORK  TO  LINK  THE  RMS 
INTO  DISTRIBUTED  SIMULATIONS  -  Various  projects 
within  the  GVSL  have  contributed  to  the  knowledge  of 


distributed  simulaticn.  There  was  an  initial  effort  to  use 
the  DIS  protocols.  Tiiere  was  also  some  experience  with 
a  commercial  software  package  called  VR-Link,  which  is  a 
program  that  aides  n  connecting  simulatiors  and  virtual 
reality  simulations.  Two  projects  were  performed  to 
satisfy  a  mandate  that  Army  simulations  be  HLA 
compliant.  Two  other  projects  provided  insight  into  the 
process  of  creating  distributed  simulations.  One  project 
evaluated  HLA  as  a  possible  method  of  providing 
interoperability,  but  Jt  was  rejected  due  to  its  limitations. 
The  other  project  used  HLA  to  communicate  vehicle 
dynamics  information  into  a  OneSAF  simulation. 


RMS  with  DisiiihuiS’d  inlPiriclive  Simulalion  (PIS)  and 

ModSAF  -  During  development  of  the  initial  code  base 
for  the  RMS  and  OS/TMBS  an  attempt  was  made  to 
implement  the  DIS  protocol.  A  commercial-off-the-shelf 
(COTS)  software  package  called  VR-Link  was  used  to 
provide  an  interface  between  the  RMS  and  ModSAF, 
which  it  did  very  successfully.  This  implementation 
allowed  the  simulatojrs  to  appear  and  move  around  within 
a  ModSAF  scenario.  Unfortunately,  there  were  issues 
within  the  C  Object  Oriented  Programming  System 
(COOPS)  environrrient,  which  was  being  used  for  the 
RMS  code  development  that  prevented  the  two-way 
communication  neejjed  to  provide  full  participation  within 
a  ModSAF  scenario.  The  lesson  learned  from  this  effort 
was  the  limitations  of  the  COOPS  programming 
environment. 


SOVAS  and  HLA  -  SOVAS  [1]  is  a  high  fidelity,  physics- 
based,  real-time  sirnulation  of  the  dynamics  of  a  ground 
vehicle.  It  can  be  psed  to  determine  vehicle  handling 
characteristics  and  ride  quality.  It  is  one  of  the  methods 
used  to  compute  motions  for  the  simulators  in  the  GVSL. 
This  project  was  established  in  order  to  satisfy  a 
requirement  for  all  /^rmy  simulations  to  be  HLA  compliant. 
It  was  decided  at  the  start  of  this  project  to  make  SOVAS 
natively  compliant  rpther  than  procure  separate  Gateway 
software  like  VR-Link. 


SOVAS  has  achieved  HLA  compliance  [1].  This  was  the 
first  effort  to  make  parts  of  the  RMS  and  CS/TMSB 
supporting  codes  HLA  compliant.  The  compliance  test 
used  the  DMSO  RTI  1.3NGv2  with  a  control  and 
monitoring  program  and  the  SOVAS  code  as  federates. 
The  control  prog  am  issued  all  of  the  commands 
necessary  to  test  tfje  HLA  functionality  of  SOVAS. 


The  work  on  the  SOVAS  HLA  compliance  provided 
extensive  experience  about  the  complexity  of  the  code 
necessary  to  meet  HLA  requirements.  This  project 
required  over  12,500  lines  of  code.  The  HLA  code  does 
not  only  provide  a  framework  for  the  communication  of 
information  about  objects,  attributes  and  interactions, 
but  it  also  requires  ^n  extensive  amount  of  bookkeeping 
about  all  of  the  data.  Another  important  lesson  learned 
was  how  firewalls,  and  network  security  in  general,  affect 
distributed  simulatijons  over  the  wide  area.  There  was  a 


lot  of  time  spent  trying  to  open  up  ports  and  protocols  on 
the  various  firewalls  in  order  to  run  the  HLA  certification 
testing  between  TARDEC  and  DMSO.  This  project  took 
longer  than  expected,  because  of  the  network  problems 
and  the  extra  time  needed  to  write  the  control  and 
monitoring  program. 

First  effort  to  implement  HLA  in  the  RMS  software  -  After 
SOVAS  achieved  HLA  compliance  an  effort  was  started 
by  members  of  the  GVSL  to  implement  HLA  capability 
into  the  RMS  code.  This  project  was  established  for  the 
same  reason  as  the  SOVAS  HLA  project,  to  satisfy  a 
requirement  for  all  Army  simulations  to  be  HLA  compliant. 
It  was  also  decided  to  make  the  software  natively 
compliant  rather  than  purchase  commercial  software  like 
VR-Link. 

The  existing  DIS  routines  within  the  code  were  disabled. 
The  RMS  code  base  was  modified  to  include  all  of  the 
required  functions  required  by  the  HLA  Federation 
Rules.  The  data  that  was  to  be  passed  from  the  RMS 
software  was  position,  velocity,  acceleration  and  vehicle 
orientation.  In  order  to  test  the  modified  RMS  software  a 
control  and  monitoring  program,  similar  to  the  one  used 
for  the  SOVAS  HLA  compliance  testing  was  created. 
The  control  and  monitoring  program  acts  as  a  driver  for 
the  compliance  testing  process  by  sending  requests  to 
the  RTI  to  activate  responses  from  the  RMS  software.  It 
also  acts  as  a  monitor  to  see  if  all  of  the  federation 
interactions  respond  correctly.  This  implementation  used 
the  DMSO  1.3NGV2  RTI. 

This  project  required  an  extensive  amount  of 
programming  of  the  RMS  code  and  the  control  and 
monitoring  program.  During  certification  testing  it  was 
found  that  the  HLA  code  seemed  to  be  very  fragile.  The 
code  would  hang  and  crash  for  no  apparent  reason.  As 
with  the  SOVAS  certification  project  it  was  found  that  the 
work  always  took  longer  than  planned. 

The  Dynamic  Reconfiaurable  Engineering  Workstation 

(DREW)  -  The  DREW  [6]  project  was  another  effort  by 
TARDEC  that  developed  engineering  level  simulations 
that  would  provide  interaction  of  vehicle  simulators  over 
the  Internet.  The  project’s  main  goal  was  to  show  how 
simulators  could  be  used  to  perform  design  optimization 
studies  from  remote  locations.  This  project  evaluated 
HLA  and  Network  Data  Delivery  Service  (NDDS™)  for  its 
communications  protocol.  NDDS™  was  selected 
because  it  provided  more  reliable  update  rates,  message 
ordering  and  the  monitoring  of  latencies.  This  kind  of 
reliability  was  needed  because  of  the  need  for  high¬ 
speed  update  rates. 

The  project  was  a  success,  but  it  did  not  provide  a  link  to 
DIS  or  HLA.  Some  type  of  HLA  or  DIS  interface  would 
have  allowed  the  simulators  to  participate  in  other 
distributed  experiments.  It  was  observed  during  this 
project  that  the  HLA/RTI  needed  additional  time  to 


mature  and  that  this  effort  would  make  a  good  case  for 
developing  a  real-tit|ne  RTI  with  the  features  required  by 
the  DREW. 

Vehicle  Dynamics  qnd  Mobility  Server  fVDMSf  -  The 
VDMS  provides  a  m^ans  of  simulating,  in  real-time,  high- 
fidelity,  multi-body  vehicle  dynamics,  off-road  vehicle-soil 
interaction,  collisiorj  detection  and  obstacle  negotiation. 
It  also  includes  the  ability  to  apply  autonomous  control 
algorithms  to  a  vehicle.  The  VDMS  capabilities  can  be 
applied  to  a  vehicle  in  a  distributed  experiment.  The 
vehicle  dynamics  code  used  in  this  project  is  the  same 
used  for  the  RMS. 


VDMS  was  used  in  the  Fall  2001  Simulation  Technology 
(SIMTECH)  Research,  Development  &  Engineering 
Center  (RDEC)  Federation  Calibration  Experiment 
(CalEx)  [3].  The  VDjMS  was  used  to  evaluate  the  cross¬ 
country  motion  of  up  to  ten  robotic  vehicles.  In  this 
experiment  VDMS  pommunicated  with  HLA  through  a 
Network  Interface  Unit  (NIU)  specifically  developed  for 
this  project  by  the  TARDEC  Vetronics  Technology  Area 
and  the  dynamics  dode  was  developed  from  work  from 
the  National  Advanced  Driving  Simulator  and  Simulation 
Center  (NADS-SC)  at  the  University  of  Iowa. 


More  recently  VDMS  was  rewritten  and  used  to  support 
the  Modeling  Architecture  for  Technology,  Research, 
and  Experimentation  (MATREX)  and  to  support  the 
Developmental  Te^t  Command  (DTC)  with  the  Virtual 
Proving  Ground  (VFG)  [9].  The  rewrite  was  necessary  to 
provide  a  better  capability  for  vehicle  representation  and 
to  reduce  the  amoijint  of  computer  resources  required. 
VDMS  provided  pn  engineering  level  simulation  of 
vehicle  dynamics  and  drivetrain  performance.  The  GVSL 
and  the  Vetronics  technology  Area  of  TARDEC  worked 
together  to  support!  these  two  projects.  In  the  work  with 
the  Virtual  Proving  Ground  [9]  VDMS  was  used  to 
provide  vehicle  po$itions  and  orientations  for  a  Stryker 
vehicle.  This  data  wps  communicated  through  an  NIU  to  a 
simulated  vehicle  in  OTB  using  the  DIS  protocol.  A  MAK 
HLA  Gateway  was  psed  to  communicate  the  vehicle  data 
to  other  participant^  within  the  Virtual  Proving  Ground. 


The  VDMS  projects  provided  experience  in  the 
development  of  art  NIU  for  HLA.  It  also  provided  an 
opportunity  to  mak©  improvements  in  the  dynamics  part 
of  the  VDMS  code. 


RMS  -  OTB  VERSION  2.0  COMMUNICATIONS  USING 
HLA  -  This  previous  work  with  HLA  and  various 
technologies  associated  with  the  GVSL  simulators 
showed  that  a  mofe  integrated  HLA  based  simulation 
environment  woulq  help  to  reduce  the  effort  needed  to 
incorporate  new  technologies  with  the  RMS  and 
CS/TMBS.  In  ordfr  to  provide  this  capability  to  the 
the  effort  is  being  focused  on  OTB 
OneSAF  Objective  System  (OOS). 


greatest  audience 
and  its  successor 


OOS  is  being  de'^eloped  to  be  the  next  generation 


Computer  Generated  Forces  (CGF)  that  can  represent 
and  control  a  full  range  of  operations  and  systems. 

All  of  the  past  projects  that  have  been  described  had 
specific  and  narrow  objectives.  In  order  to  create  a  robust 
and  flexible  environment  it  is  necessary  to  create  a  true 
HLA  Federation.  This  is  the  reason  that  the  FEDEP  is 
being  used.  Many  of  the  items  in  the  FEDEP  are  not 
applicable  to  this  project,  but  by  formalizing  the  process  it 
creates  a  framework  that  will  allow  future  Federations  to 
be  generated  much  more  easily. 

There  are  many  facets  of  the  RMS  environment  that 
need  to  be  understood  and  coordinated  in  order  to  make 
a  complete  link  between  the  motion  simulators  and  a 
distributed  simulation  environment  such  as  OTB.  Some 
of  the  information  needed  includes  the  following:  vehicle 
characteristics,  vehicle  orientation,  vehicle  location  within 
the  terrain  database,  vehicle  speed  and  direction,  and 
how  the  terrain  will  be  visualized  within  the  simulator.  In 
addition,  there  are  the  HLA  aspects,  which  include:  the 
Run  Time  Infrastructure  (RTI)  to  be  used,  development 
of  the  Federation  Object  Model  (FOM)  and  the 
Simulation  Object  Model  (SOM)  for  each  separate 
simulation  within  the  distributed  environment.  These 
Object  Models  formally  set  forth  all  of  the  data  to  be 
shared  within  a  distributed  simulation. 

Much  of  the  preliminary  work  necessary  for  the  creation 
of  an  integrated  HLA  interface  for  the  RMS  and 
CS/TMBS  is  already  available.  In  order  to  validate  that 
effort  a  federation  consisting  of  the  RMS  and  OTB 
Version  2.0  is  being  implemented.  The  Federation 
Development  and  Execution  Process  (FEDEP)  version 
1 .5  is  being  used  to  plan  and  formally  document  this 
effort.  The  FEDEP  version  1 .5  is  a  6  step  process  that 
has  been  developed  by  the  simulation  community  to 
provide  a  way  of  organizing  the  activities  that  might  be 
needed  in  putting  together  a  distributed  simulation.  The 
following  is  a  summary  of  the  activities  performed  in  each 
step  of  the  FEDEP  to  create  a  distributed  federation 
linking  the  RMS  with  OTB  version  2.0: 

.  Step  1 :  Define  Federation  Objectives  -  The  Federation 
Objective  is  a  force-on-force  engagement  at  the  platoon 
level  with  the  RMS  represented  as  a  separate  vehicle. 
This  vehicle  must  be  able  to  observe  the  engagement 
and  be  seen  as  a  vehicle  in  the  scenario.  The  RMS 
software  must  be  capable  of  receiving  information  about 
instances  of  vehicles  in  OTB  and  display  each  individual 
vehicle  accurately  as  well  as  their  movement.  Each 
vehicle  that  can  be  represented  by  the  RMS  will  be 
tested  with  the  OTB  scenario. 

Step  2:  Develop  Federation  Conceptual  Model  -The 
Federation  Conceptual  Model  provides  more  detail 
about  each  federate  within  the  federation.  The  OTB 
Federate  will  be  running  the  force-on-force  scenario. 
This  scenario  will  consist  of  a  blue  force  M1A2  tank 


platoon  moving  to  n  defensive  location  and  a  red  force 
will  be  a  T80  tank  p'latoon  that  will  be  attacking  along  a 
line  that  will  intersect  the  blue  defensive  position.  The 
RMS  will  be  configur^ed  as  one  of  four  vehicles,  HMMWV, 
M1,  M2  or  Stryker.  The  RMS  vehicle  will  move  with  the 
blue  force  to  the  dijfensive  position  and  then  observe 
the  red  force  approach  and  observe  the  engagement. 

Step  3:  Design  Fecjeration  -  A  force-on-force  scenario 
has  been  developer!  and  tested  in  0TB  version  1 .0.  The 
scenario  will  be  conjigured  in  0TB  version  2.0  using  the 
Military  Scenario  C'evelopment  Environment  (MSDE). 
MSDE  is  part  of|  the  0TB  version  2.0  software 
distribution.  In  orde  to  have  an  RMS  federate,  it  is  now 
necessary  to  dete-mine  the  capabilities  of  the  RMS 
software.  In  order  to  support  all  of  the  HLA  requirements, 
that  have  been  defined  in  Step  1  and  Step  2  the  RMS 
will  need  to  provide  its  location,  velocity,  direction  and 
orientation.  It  will]  also  have  to  be  able  to  accept 
information  about  itistances  of  other  vehicles  from  0TB 
and  display  those  v^shicles  in  the  correct  location 


Step  4:  Develop 


•ederation  -  Development  of  the 


federation  will  requi'e  detailed  analysis  of  each  federate 
in  order  to  develop  their  Simulation  Object  Models.  The 
Simulation  Object  Model  is  the  list  of  data  in  a  simulation 
that  has  been  forr  latted  in  accordance  with  the  HLA 
Object  Model  Template. 


The  following  activities  will  be  necessary  to  complete  this 
step;  I 

1)  Determine  all  of  t'le  objects,  attributes  and  interactions 
that  need  to  be  communicated  from  the  RMS.  This  will  be 
the  Simulation  Ot)ject  Model  (SOM)  for  the  RMS 
software. 

2)  Select  a  suitable  Federation  Object  Model  (FOM)  that 
is  supported  by  OTEL  This  will  also  be  the  SOM  for  0TB. 

3)  Make  sure  that  c.ll  of  the  data  described  by  the  RMS 
SOM  is  also  in  the  OTB  SOM/FOM. 

4)  Make  the  necessary  modifications  in  the  RMS  software 
to  satisfy  HLA  requirements. 

Steps  5  &  6  -  Integrate  and  Test  Federation  and  Step  6: 
Execute  Federation  and  Prepare  Results  -  These  steps 
consists  of  testir  g  the  Federation  to  correct  any 
problems.  Once  the  Federation  has  been  successfully 
integrated  it  will  ba  run  several  times  with  the  RMS 
configured  as  a  different  vehicle.  In  addition  the  path  that 
the  RMS  vehicle  takes  will  be  modified  to  test  how  well 
the  RMS  can  drive  \|vithin  an  OTB  scenario. 

CONCLUSION 

Linking  the  RMS  |and  CS/TMBS  to  other  distributed 
simulations  is  an 
researchers,  tester 


important  capability.  It  will  give 
and  trainers  another  tool  to  use  to 


provide  the  best  ecuipment  to  the  soldiers  in  the  field. 


The  process  of  linking  legacy  software  into  a  distributed 
simulation  is  a  non-trivial  task.  The  Federation  Execution 
Development  Process  provides  an  excellent  framework 
to  guide  these  kinds  of  activities,  however  there  is  an 
extensive  amount  of  detail  that  must  be  filled  in  by  the 
user. 

There  have  been  many  lessons  learned  about  the 
development  of  HLA  compliant  simulations,  specifically 
the  need  to  provide  sufficient  time  to  write  and  test 
software.  In  addition  the  requirements  for  network 
communication  must  be  addressed  early  in  the  project. 
Many  of  the  projects  required  the  development  of 
additional  software  to  provide  an  HLA  capable  simulation. 
The  FEDEP  is  an  excellent  tool  which  can  focus  the 
effort  to  create  a  distributed  simulation  environment 
using  HLA. 
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DEFINITIONS,  ACRONYMS, 

ABBREVIATIONS 

CGF  -  Computer  Generated  Forces 


CS/TMBS  -  Crew  Station/Turret  Motion  Base  Simulator 

DIS  -  Distributed  Interactive  Simulation 

DMSO  -  Defense  Modeling  and  Simulation  Office 

GVSL  -  Ground  Vehicle  Simulation  Laboratory 

Mbps  -  Mega  bits  per  second 

OneSAF  -  One  Semi  Automated  Forces 

0TB  -  OneSAF  Test  Bed 

RMS  -  Ride  Motion  Simulator 

SCRAMNet  -  Shared  Common  RAM  Network 

SOVAS  -  Symbolically  Optimized  Vehicle  Analysis 
System 

VDMS  -  Vehicle  Dynamics  and  Mobility  Server 


COOPS  -  C  Object  Oriented  Programming  System 


